Web Services Security

OIPA uses JAS-WS for implementing Web Services. For securing web services, WS-Security standards are used to perform authentication and authorization against OIPA user accounts. The SOAP header contains the appropriate security credentials. The password can be sent as a digest or as a text.

The SOAP header with WS-Security would look like the following when a password digest is used:

SOAP header with WS-Security
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-1" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>username</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">passwordencrypted</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">kC5eI6iq8x17/qA3mzs6/g==</wsse:Nonce>
<wsu:Created>2010-03-22T14:12:34.223Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>

By default, starting with the 10.2.2.0 release, OIPA will not allow web services to be invoked with hashed passwords. To continue using PasswordDigest, the property webservice.allowHashedPassword should be set to Yes. For more details, see the System Properties document available in the current release Documentation Library under Policy Administration Libraries of Oracle Help Center.

For more information on the WS Security standard please refer to the website:

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

TODO: Add Security for SOAP to REST Services

For OIPA REST services testing we are following the No-Auth header-based authorization approach because the current SOAP authorization flow is header-driven and expects these values explicitly.

REST requests are expected to provide the required authentication values explicitly in the request headers.

When testing OIPA REST services from Postman, select No Auth under Authorization and pass the following headers with the request:

  • Username = <username> Eg: qatester3

  • Password = <password>

  • PasswordType = PasswordText

PasswordType is mandatory and case-sensitive. The supported values are

  • PasswordText for plain text passwords

  • PasswordDigest for hashed passwords.

Hashed-password support for REST services is controlled by the same configuration that is already used for SOAP services:

webservice.allowHashedPassword=No

With the current value set to No, hashed-password authentication using PasswordDigest is not enabled. Requests must therefore use PasswordText.

This approach applies to REST endpoints such as /PASJava/rest/fileReceived, /PASJava/rest/policyValuation, /PASJava/rest/exposedComputation, and /PASJava/rest/processPolicy.

Using Cookies in the OIPA application

The OIPA application is accessed by users through a Web Browser. OIPA uses session cookies to manage user sessions, so cookies must be enabled in the browser.

To allow the use of cookies in a browser, follow these steps:

  • Internet Explorer: Open the Privacy tab of the Internet Options dialog, then select the Sites popup dialog and add the OIPA server address to the list of Allowed sites.

  • Mozilla Firefox: Go to Settings > Privacy and Security, then select an appropriate option that allows OIPA cookies.

  • Google Chrome: Navigate to Settings > Privacy and security > Cookies and other site data. In the Sites that can always use cookies section, click Add. The Add a site page appears. Enter the OIPA server address and, then click Add.

  • Microsoft Edge: Navigate to Settings > Cookies and site permissions > Manage and delete cookies and site data, then in the Allow section, click Add. The Add a site page appears. Enter the OIPA server address and, then click Add.

OIPA uses 'jSessionIDHeader' in the HTTP request header to manage data associated with the user's session. When user first logs into the OIPA application successfully, system creates an unique sessionID and passes to the browser. Browser sets this to jSessionIDHeader and retains this for the duration of session. When user logs out or session expires, browser deletes this sessionID. Requests that do not contain valid session IDs are not processed by the server.

If the application server is behind any HTTP proxy server, HTTPOnly & SecureCookie flags shall be enabled for the cookies. The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text.

Additional Sources of Security Information

In addition to securing the OIPA application, all infrastructure resources –Linux/Windows servers, J2EE application and database servers – that compose an OIPA environment must be secured. The following list of links should be helpful while planning how to secure an OIPA environment.

Coherence 15.1.1.0.0 User Guide

https://docs.oracle.com/en/middleware/standalone/coherence/15.1.1/integrate/index.html

Securing Oracle Coherence 14.1.1

https://docs.oracle.com/en/middleware/standalone/coherence/14.1.1.0/secure/securing-oracle-coherence.pdf

Oracle 19c Database

https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/index.html

Oracle 26ai Database

https://docs.oracle.com/en/database/oracle/oracle-database/26/index.html